There's currently an issue with mach-try-perf where the double-push is taking a very long time. Given the changes in bug 1836069 will only improve performance later on, we should explore if we can do two builds within a single push instead to resolve part of this issue sooner.

This wouldn't resolve all of the issues from bug 1836069 because we would still need the remote revision to build a compare view link, but we would only need one revision instead of two.

I managed to get double-builds working for linux, and android here: https://treeherder.mozilla.org/jobs?repo=try&revision=0a002512a56429e478ca46e452c5135dff583f8f

The issue with android builds is that the routes seem to have changed or aren't setup correctly. That said, I've also been hitting other issues with that build locally. For desktop, I anticipate that mac, and windows will work fine like Linux since I'm forcing artifact builds there. For android, artifact builds are busted so we need to do a full build which is where these issues seem to be coming from.

I managed to get compare view to work with this double-push as well and put up a PR here to discuss the approach: https://github.com/mozilla/treeherder/pull/7757

I won't dig any deeper into the android build issues. There's no sense in getting that working now given the incoming mono-repo changes might affect how they work. It might also fix the artifact mode issue which would solve the issue I'm currently hitting since we wouldn't need to rebuild. Instead, I'd add a flag to mach try perf like --fast-push that would use this double-build method. It would be disabled if any android tasks get selected.

Try run here for Windows, and Linux passing now: https://treeherder.mozilla.org/jobs?repo=try&revision=fb722983b592330ac7cbcd02ca1c09516f11fcc8
Mac needs some more work, and I think it might be hitting some of the same issues as android so maybe we could make android available too if we can fix mac.

Passing builds, and tests with linux, and windows: https://treeherder.mozilla.org/jobs?repo=try&revision=ea5e9a58319d786c3507c8db64f7962b96820068

Here's a passing try run for mac: https://treeherder.mozilla.org/jobs?repo=try&revision=666581434cff891a3adbb18dfb37e0e1c9f08680

Android is still problematic, and I'm currently in a "circular failure" where fixing one of the failures triggers the other and vice versa so we'll leave it until artifact mode is fixed for it.

This patch adds new *-base-rev platforms to make it possible to run mach-try-perf in a single push. Currently, we need to run two try runs to obtain a comparison with the base-revision of a developers patch. With this patch, we'll be able to do it all in a single push since the *-base-rev builds will use the base-revision of the push instead of the new-revision (GECKO_HEAD_REV).

To add these platforms, a new environment flag is added to existing builds that run perftests (PERF_BASE_BUILD). This is then used to determine when a build should be duplicated into two (a standard, and a base-rev build) using a transform. The alternative here was to build new platforms for each case, but this isn't sustainable for maintenance since it'll require us to add new platforms. Furthermore, the transform method lets us disable/hide these everywhere and only enable them for mach-try-perf.

Depends on D190101

Is there still ongoing work here / related to bug 1836069? I'm curious how mach try perf will work in our brave new non-hg world which is soon upon us. :-)

The patch for this has been blocked on a review so no ongoing work here, and I haven't heard of any developments in the remote revision bug either. :glob, will we still be getting the remote revisions when we do pushes to try (without lando) when we start using git? Also, will there be a way to test the try runs with the git-based system before it releases?

So from :tcampbell on Matrix, the remote revisions will still be there for a bit, but it's quite likely they will be removed at some point after that.

From the discussion there, an idea was to use UUID/markers to match the base+new try runs instead of catching the base and new revisions. If that idea works out, then we won't need to worry about the remote revisions anymore (and the hg->git switch). This would also give us the ability to support push-to-lando.

I've filed bug 1949264 to look into that. I'm not going to link it to this bug though because I believe using double-builds could still result in CI savings, and reducing overall try server (or lando) loads. It could also still be implemented after any changes in bug 1949264.